FlutterでRiverpodとMockitoを使ってProviderのテストしてみた

FlutterでRiverpodとMockitoを使ってProviderのテストしてみた

Clock Icon2024.04.15

こんにちは。
モダンアプリコンサル部の坂本です。

前回の記事ではFlutterでMockitoを使用した依存関係のあるクラスの単体テストを紹介しました。
今回はRirverpod Generatorを用いて製造されたNotifierクラスについて、Providerを用いたテストを記述してみようと思います。

Riverpod Generatorの使い方などはこちらの記事を参考にしてみてください。

Riverpod Generatorに適用させる

前回の構成をRiverpodのNotifierでステート管理を行う構成に変更し、Riverpod Generatorに適用させます。
DIもRiverpodで行うよう変更しています。

上記でBuild Runnerを走らせると、login_controller.g.dartが生成されます。
Riverpod Generatorではbuildメソッドの戻り値に応じてNotifierを自動選択してくれますが、今回のケースではAutoDisposeNotifierが生成されました。

テストコード

先に結果から。
記述したテストコードが以下になります。
(長いので一部省略)

簡単な説明

前回と比較するとずいぶんと様変わりした印象です。
今回の変更によってテストの流れが以下のようになりました。

  1. (必要に応じて)スタブを定義
  2. ProviderContainerを生成(依存関係のoverride)
  3. Providerをテスト用のListenerでlisten
  4. Notifier(Controller)の処理を発火
  5. Listenerに期待通りの値が流れてきているかをverifyで評価

2でProviderContainerというオブジェクトが登場した点、テスト方法として3でListenerを登録し、5で「Listenerに期待通りの値が流れてきているか」を評価している点が大きく異なります。 この2点について簡単に説明していきます。

ProviderContainer

ProviderContainer createContainer() =>
    ProviderContainer(
        overrides: [
          authRepositoryProvider.overrideWithValue(authRepository),
        ]
    );

ProviderContainerはProviderの状態を監視するオブジェクトです。

通常、ProviderContainerは暗黙的に生成されるため、明示的な利用をしなくても良いのですが、テストにおいてはプロバイダの状態はテストごとにリセットしたいため明示的に生成します。

また、ProviderContainerはProviderの挙動をoverrideすることができます。
ここではauthRepositoryProviderMockAuthRepositoryを返却するようoverrideしています。

Listener

RiverpodのProviderにはListenerを通してステートの変更を監視するlistenメソッドが用意されています。
今回のテストではこの仕組みを利用し、ValueChangeListenerというインターフェースを定義の上モックを生成し、モックの呼び出しを評価しています。

テストに用いるListenerのinterfaceです。

abstract interface class ValueChangeListener {
  void call<T>(T previous, T next);
}

listener.callloginControllerProviderのステートの変更を購読しています。

container.listen(loginControllerProvider, listener.call);

評価したい処理を発火し、listener.callに対する呼び出しを評価しています。

await controller.login(loginId: "[email protected]", password: "8peJuzJ*naBd");

verify(
  listener.call(
    isNull,
    isA<User>()
      .having((p0) => p0.loginId, "loginId", "[email protected]")
      .having((p0) => p0.name, "name", "田中 太郎"),
  ),
).called(1);

少し回りくどい印象がありますね。
controller.stateを直接評価するのではダメなのか?という疑問が出てきます。
ここまでのケースだとそれでも評価可能ですが、以下に記述するAsyncNotifierの評価を行う場合、評価しきれない部分が出てきます。

AsyncNotifierの評価

ここまでのケースではNotifierに初期値は不要でした。
しかし、実際の開発においては初期値をWebAPIなどから取得するケースも多いのではないでしょうか。
Riverpodを用いた開発ではこういったケースの多くにはAsyncNotifierが使用されます。

class AsyncAuthRepository {
  Future<User?> verifyLoginUser() async {
    // セキュアストレージからアクセストークンとか拾って、ユーザー情報取得までやってる風
    await Future.delayed(const Duration(microseconds: 500));

    return const User(loginId: "[email protected]", name: "坂本 勇人");
  }

  Future login({required String loginId, required String password}) async {
    // WebAPIのレスポンスを待ってる風
    await Future.delayed(const Duration(microseconds: 500));

    if (loginId == "[email protected]" && password == "%!vTdkQ#wJ7|") {
      return const User(loginId: "[email protected]", name: "坂本 勇人");
    } else {
      throw Exception("ログインに失敗しました。");
    }
  }
}

上記では、AsyncLoginControllerbuildメソッドでログイン状態の確認を実施しています。
ログイン状態の確認はAsyncAuthRepository.verifyLoginUserで非同期に行われるため、戻り値はFutureまたはFutureOrになります。

この状態でBuild Runnerを走らせるとAsyncLoginControllerAutoDisposeAsyncNotifierを継承します。
AutoDisposeAsyncNotifierは遡るとAsyncNotifierBaseを継承しており、ステートはAsyncValueでラップされ、loading、errorなどの状態を管理することになります。

このケースでのAsyncValueの初期値はloadingになっており、処理が完了した場合やエラー発生時に状態が変化します。
そのため、今回のケースを評価しようとした場合、controller.stateのみを評価すると以下のようにloadingが正常に動作しているか評価ができない状態になります。

// ログイン済みの場合のスタブを生成
when(
  authRepository.verifyLoginUser(),
).thenAnswer((_) {
  return Future.value(const User(
    loginId: "[email protected]",
    name: "田中 太郎",
  ));
});

final container = createContainer();
// Controllerの初期化まで待機
await container.read(asyncLoginControllerProvider.future);

// Controllerを取得
final controller = container.read(asyncLoginControllerProvider.notifier);

// 初期化の結果は評価できるけど、途中経過が評価できない
expect(
  controller.state,
  isA<AsyncData<User?>>()
      .having((p0) => p0.value!.loginId, "loginId", "[email protected]")
      .having((p0) => p0.value!.name, "name", "田中 太郎"),
);

このようなケースではlistenerのpreviousnextを評価したり、verifyInOrderで順序を評価することで、状態の遷移を評価することができます。
変更されたloginメソッドへの評価を含めたものを以下に記載します。

まとめ

いかがでしたでしょうか。
RiverpodのNotifierを評価する場合、listenerを用いることで状態の遷移を評価できるため、より詳細なテストを実施できるようになりました。
初期値の存在しないNotifierであれば結果のみ評価するのでも十分なケースがありますが、手法が一貫している方が迷いがなくなると思うので、初期値の有無や非同期処理の有無に関わらずlistenerを用いた評価をしていこうと思いました。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.